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I . I NTgODUCTI ON 



It is obvious that it is the database system era in 
computer technology and applications. Database processing 
has grown significantly in computer science areas and also 
in management of certain organizations. 

An important consideration in database development is 
to store data in such a way that it can be used for a wide 
variety of applications and can be changed and quickly 
and easily. To achieve the flexibility of data usage, three 
aspects of database design and implementation are important. 

First, the data should be independent of each other and 
functionally dependent on the key value. Second, it should 
be possible to interrogate for user's requirements using 
application programs or the DBMS itself. Third, these data 
items should provide useful information for decision makers 
to analyze, to investigate, to plan and to manage in a 
certain organization. 

It is very difficult to develop database systems which 
perform in an optimal fashion. There are many different ways 
in which data can be structured and each has its own 
advantages and disadvantages. Different users want to use 
different data/information. It is hardly possible to satisfy 
all of the users with one type of data organization. 
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The normal form concepts of relational database will be 
used to develop an Intelligence Database, because the 
Relational Database Management System supports Independence 
better than other models and is easier to implement. 

Chapter II addresses the basic concepts of database, 
which relates to the database system development for the 
Intelligence Database. Chapter III addresses the 
introduction to database design, which includes conceptual 
database design and physical database design. Chapter IV 
describes how the Intelligence Database is designed using 
Semantic Database Model. ?irst of all, the SDM is designed; 
then a relational or network model is applied and 
implemented. Chapter V describes Relational database 
design, which Includes relational Normal Forms and the 
characteristics of relational database and conversion of SDM 
into Relational database design. Chapter VI addresses the 
implementation which is implemented on the ORACLE Database 
Management System. Finally, Chapter VII presents conclusion 
and recommendations based on the research presented in the 
thesis . 
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II. BASIC CONCEPT OP DATABASE 



A. WHAT IS A DATABASE? 

First of all, there is the database itself - a 
collection of data stored on disks, drums or other secondary 
storage media. Second, there is a set of ordinary batch 
application programs which run against this data, operating 
on it in all the usual ways. Third, the database is 
'integrated'. This means that the data base contains the 
data for many users, not just for one, which in turn implies 
that any one user will be concerned with just a small 
portion of it. According to [Ref. 4], the definition of 
database is a collection of stored operational data used by 
the application systems of some particular enterprise. Some 
examples of enterprise are manufacturing companies, banks, 
hospitals, etc. 

B. WHY DATABASE? 

There are many answers to this question. One general 
answer is that it provides the enterprise with centralized 
control of its operational data. This is in sharp contrast 
to the situation that prevails in most enterprises today, 
where typically each application has its own private files 
so that the operational data is widely dispersed, and there 
is little or no attempt to control it in a systematic way. 
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1 • 4iliSi§.g§ 2f 

First, database processing enables rrore 
information to be produced from a given amount of data. 
Second, the elimination or reduction of data duplication 
saves file space, and to some extent, can reduce processing 
requirements. The most serious problem of data duplication 
is that it can lead to a lack of data integrity. A common 
result of a lack of data integrity is conflicting reports. 
Third, creation of program/data independence - the immunity 
of applications to change in storage structure and access 
strategy, which implies that the application concerned do 
not depend on any one particular storage structure and 
access strategy. Another advantage is better data 
management. When data is centralizied in a database, one 
department specializes in the maintenance of data. That 
department can specify data standards and ensure that all 
data adhere to the standards. When someone has a data 
requirement, he can contact one department instead of many 
file maintenance groups. F rthermore, centralization of data 
management leads to economies of scale. 

2. Disadva^age of Database 

A major disadvantage of database is that it can be 
expensive. The DBMS may occupy so much main memory that 
additional memory must be purchased. Even with more memory, 
it may monopolize the CPU, thus forcing the user to upgrade 
to a more powerful computer. Once the database is 
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implemented, operating costs for some systems will be 
higher. Sequential processing, for example, will never be 
done as fast as in the database environment, because of the 
extra overhead. 

Another disadvantage is that database processing 
tends to be complex. Large amounts of ata in many different 
formats can be interrelated in the database. Both the 
database system and the application programs must be able to 
process these structures. This requires more sophisticated 
programming. Backup and recovery are more difficult in the 
database environment. This is because of increased 
complexity and because the database is often processed by 

several users concurrently. Determining the exact state of 
the database et the time of failure may be a problem. Given 
that, it may be even more difficult to determine what should 
be done next. 

The third disadvantage is that integration, and 
hence centralization, increases vulnerability. A failure in 
one component of an integrated system can stop the entire 
system. This event is especially critical if, as is often 
the case, the operation of the user organization depends on 
the database. 

C. AN ARCHITECTURE FOR A DATABASE SYSTEM 

The architecture of a database is outlined in Figure 
2.1 [Ref. 4]. This figure is in broad agreement with that 
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proposed by the AN SI/S? ARC Study Group on Bata Ease 
l^anageitent Systems. The architecture is divided into three 
general levels: internal, conceptual, and external. Broadly 
speaking, the internal is the one closest to physical 
storage, the one concerned with the way in which the data is 
actually stored; the external level is the one closest to 

the users, that is, the one concerned with the way in which 

% 

the data is viewed by individual users; and the conceptual 
level is a 'level of indirection' between the other two. 
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N'ext, the various components of the system will he 
examined. The users are either application programmers or 
remote terminal users of any degree of sophistication. Each 
user has a language at his disposal. It will he a 
conventional programming language, such as COBOL, PL/1, etc. 

Each user is provided with a workspace, which acts as 
the receving or transmitting area for all data tranferred 
between the user and the database. The user is said to view 
the database by means of an external model. An external 
model is thus the information content of the database as it 
is viewed by some particular user. 

Each external model is defined by means of an external 
schema, which consists of descriptions of each of the 
various types of external records in that external model. In 
addition, there must be a definition of the mapping between 
the external schema and the undering conceptual schema. 

The conceptual model is a representation of the entire 
information content of the database, again in a form that is 
somewhat abstract in comparison with the way in which the 
data is physically stored. The conceptual model is defined 
by means of the conceptual schema, which includes 
definitions of each of the various types of conceptual 
records. If data independence is to be achieved, these 
definitions must not involve any considerations of storage 
structure or access strategy. Thus there must be no 
reference to stored field representations, physical 
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sequence, indexing, hash-addressing, or any other storage/ 
access details. The conceptual model is a view of the total 
database content, and the conceptual schema is a definition 
of this view. The definition in the conceptual schema is 
intended to include a great many additional features, such 
as the authorization checks and validation procedures. 

The internal model is a very low-level representation 
of the entire database; it consists of multiple occurrences 
of multiple types of internal records. The internal model is 
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schema , 


which 


not 


only 


defines 


the 


va ri ous 


types of 
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records 


but 


also 
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represented, what physical sequence the stored records are 
in , etc. 

The conceptual/internal mapping defines the 
correspondence between the data model and the stored 
database; it specifies how conceptual records and fields map 
into their stored counterparts. If the structure of the 
stored database is changed - if a change is made to the 
storage structure definition - the conceptual/internal 
mapping must be changed accordingly, so that the conceptual 
schema may remain invariant. 
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DBMS intercepts the request and interprets it; (3) the DBMS 
inspects, in turn, the exte nal schema, the 
external/conceptual mapping, the conceptual schema, the 
conceptual/internal mapping, and the storage structure 
definition; and (4) the DBMS performs the necessary 
operations on the stored database. 

D. PROGRAMS IN TYPICAL DATABASE PROCESSING 

•Figure 2.2 shows the approximate relationships of the 
major types. Online processing requests or transactions are 
provided by users at terminals. The requests are sent to 
the processing computer over communications lines. 

The communications control program (CCP) has several 
important functions. It provides comunica tions error 
checking and correction, coordinates terminal activity, 
routes messages to the correct next destination, and 
formats messages for various types of terminal equipment. 

The utility programs are provided by either the DBMS or 
the hardware vendor. These programs provide a wide variety 
of services. Query/update utilities provide generalized 
retrieval and update of the database. 

For normal processing, the DBMS receives data and 
stores it for subsequent processing. This system acts as a 
sophisticated data librarian. The DBMS allows application 
programs and utilities a wide variety of access strategies. 
It also enables these programs to have different views of 
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the same data so that applications can use data in a format 
tha t is familiar and useful to them. 

The DE^S also has features to provide security over 
data; the tools provided ensure that only authorized data 
are accessed. Also, the DBMS controls concurrent processing 
and includes features to provide backup and recover. 

The final type of program involved in database 
processing is the operating system. This set of programs 
controls the computer's resources. The DBMS sends requests 
for input/output services to operating system. 
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III. INTRODUCTION IQ QAIASAQE DESIGN 



A. CONCEPTUAL DATABASE DESIGN 

Database Managenent Systems have evolved from file 
systems to answer two critical needs: support for more 

inter-related data and support for sharing data among many 
diverse applications. These goals are being achieved, in 
part, by providing DBMS software to physically link related 
data into complex structures using such mechanisms as 
pointer chains, indices and sequential positioning. They are 
also achieved by the development of database design 
methodologies and rules. 

To reduce the complexity of using DBMSs, designers have 
developed special interfaces to these systems that decompose 
their use into easily understood phases. Thus, most DBMSs 
have Data Description Languages (DDLs), Data Manipulation 
Languages (DMLs) and Query Languages. The DDL is used to 
specify the design of the database. The DML is used to 
generate application programs that access the database in 
terms of the objects specified using the DDL. The Query 
Language is used for more 'casual' database accesses. The 
DML is orinted toward the development of database access 
programs that are efficient to execute while Query Languages 
are orinted towards ease in writing such programs. 
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1 • Ifee Level Of ign 

A database must encompass all aspects of the data 
to be stored - beginning with details of how it is presented 
to different users and ending with how it is to be 
represented on the hardware of a particular installation. To 
achieve this in an orderly and correct fashion, the design 
process has been structured into the three distinct phases 
shown in Figure 3.1. The first phase, which may be called 
'view design', is the identification and design of 
interfaces for the different end-user groups. Each end user 
requires a particular 'view' of the database to support his 
own application idiosyncrasies. A view should present data 
in the structure which is most effective for the user. This 
may be reports, natural language text. The view must provide 
tailored update facilities to manipulate the database. 
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Figure 3.1 Phases in Database Design 



22 



The next phase which may he called 'conceptual 
design' is the integration of all the concepts which are 
necessary to support the various application views. In 
effect, conceptual design is the production of a 'community' 
model in which the idiosyncrasies of the individual views 
are resolved. At the conceptual level, data should appear in 
a structure which is most perspicuous for concept 
integration. It should explicitly define how concepts are 
related one to another; it should not contain any 
implementation detail; and it should he locally modifiable. 

The final phase, 'physical design', is the mapping 
of the conceptual model on to physical computing devices. In 
this phase, performance considerations must he analyzed and 
shown compatible with application requirements. With most 
database management systems, the physical mapping is 
partially hidden and 'tuning' is allowed on only a fixed set 
of parameters. 

The Contents Of A Concefitual Design 

The conceptual design of a database serves two 
functions. It is used in interactions with applications 
programmers to verify the correctness of the program being 
developed. It is also used as a guideline for the physical 
designers - specifying to them what must be implemented 
without constraining how it is implemented. To achieve these 
objectives the following kinds of information must be 
determined in the design process: 
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* The structure of the database's conceptual objects 
The structure of its basic functions and update 
procedures 

* Integrity constraints on the database. 

The conceptual objects of a database are all very 
important to the running of an enterprise whether they be 
people, procedures, events or the inter-relationships among 
these. Such objects must be grouped into types which 
identify their significant attributes and processing 
constraints . 

Because a major goal of database management is 
data sharing, it is expected that the updates of each user 
will be apparent to the other users of the data. This makes 
it important that the necessary side effects of such changes 
be understood and correctly implemented by all application 
groups. This can be facilitated by Including in the 
conceptual design specification of the basic update 
operations for objects in the database. 

It is also useful for the onceptual design to 
Include, via function and procedure specification, 

conventions for naming individuals that exhibit a correct 
sensitivity to updates. In addition to the integrity 

constraints maintained by the primitive update operations 
and those enforced by the type declarations, there may be 
many more sophisticated constraints that must be maintained 
for the database. 
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3» A £on££Elua,l figsign 

What makes a good conceptual design? It is 

possible to itemise a useful set of properties that 
characterise a good conceptual design as follows: 

* Concept complete : guarantees not only that useful 

objects are not left out of the database but also that 
physical database designers are not inappropriately 
constrained. It is true that for many derived concepts 
the derivation can only be made in one direction. 

’!• Unbiased toward applications : groupings which favor 

one application at the expense of others should be 
identified and removed when possible. 

* Evolvable : it should be locally modifiable and it 

should be flexible in supporting user interpretations. 
Independence of existing installation and DBMS 
constraints : initially tailoring a design to fit the 
limitation of the current state of its intended support 
system makes it difficult to separate out these 
restrictions when the support system changes or is 
replaced. The better approach is to develop the design 
independence of such limitations and conventions first, 
then tailor it to the system. 

^ Tools And Method o logi es 

The primary tool in database design is the 
language used to specify the design. Such a specification 
language is a tool in the sense that its vocabulary and 
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syntax shapes the way designers percieve the application 
they are modelling. A model too primitive in its vocabulary 
requiries more complicated concepts to he built up, 
producing a specification that is difficult to understand 
and therefore to use and to verify. 

Zach of the following properties contribute to 
value of a good data model : 

1. It should be expressive : a data model that is 
sensitive to important distinctions will guide its 
users to include the concepts and objects necessary to 
a good design. 

2. It should not over cons t rain implementors : because a 
conceptual design is the mechanism used to instruct 
physical database implementors the model on which it is 
based should not imply particular implementation 
strategies . 

3. A data model should have a formal basis: this relieves 

the designer of ambiguity and provides the physical 
designers and implementors with a sound foundation for 
verifying their work. 

4. A data model should be widely applicable: A conceptual 

design for an extensive enterprise may need to 

■encompass applications that are very dynamic in terms 
of interactions among the different objects of interest 

5. A data model should be understandable : A conceptual 
design for an extensive enterprise can be both very 
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large and very complex. To show even a part of a 
specification to an end user to check its correctness, 
it is necessary that the data model in which it is 
expressed provides some kind of non-technical 
presentation mode. 

5 • l!SEl§!!!§°iiii23 ign £omB20SEis 

A diagram of the spectrum of inputs to and outputs from 
the implementation design is shown in Figure 3.2. 
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Inputs ere as follows? 

1. DSMS-independent schema - The major result of the 
conceptual design phase, to te refined ty the 
implementation design phase. 

2. Operational requirements quant i f i ca t i on - Specification 
for integrity, recovery, security, and response tire 
limits. 

3. Volume and usage quantification - Database size in 
terms of data occurences and application frequencies. 

4. Consistency constraints - Rules for iceeping data 

elements consistent, rules for dealing with 

inconsistent data. 

Outputs are as follows? 

1. DBMS-processible schema - Specifications for a database 
structure that can be implemented with a specific IRrS. 

2. Subschemas - DEMS-process ible database structure 
consistent with individual user views and security 
constrain ts . 

3. Guidance to the database operations group - a summary 
of requirements, constraints, and available date on the 
hardware/software environment to the DBA. 

B. PHYSICAL DATABASE DESIGN 

The second stage of database design -physical design- 
is a stage of transformation. The loe*ical schema is 
tranformed into the particular data constructs that are 
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available with the DBMS to be used. Whereas the logical 
design is DBMS-independent, the physical design is very much 
DBMS-dependent. Detailed specifications of the database 
structure are produced. These specifications will be used 
during implementation to write source statements that define 
the database structure to the DBMS. These statements will be 
compiled by the DBMS and the object form of the database 
structure will be stored within the database. as 
illustrated in Figure 3.3. [Ref. 3] 



I Logical 
[Database 



I 



Physical 



1 Physical 1 
I Be s i gn ' 




[Object 



Figure 3.3 Role of Physical Design 



1 ♦ PfeZSical Design Environment 

The design environment is basically the same for 
both file design and physical database design. However, many 
design decisions for files are much simpler than for 
multiple-record-type design. First, the major categories of 
inputs and outputs for the physical design phase are 
illustrated in Figure 3.4. 
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Figure 3.4 Physical Environment 
In general, physical design considers new 
parameters, but previous tentative decisions on access 
paths and record allocation are finalized in this phase. 
Parameters regarding data volume, application processing 
frequency, and sequence o-" operations in aplication programs 
are the same as those required for implementation design. 
New parameters introduced at this stage are those specific 
to DBMS and operating system access methods, those specific 
to describe physical device capacity limitations and timing 
characteristics and all operational requirements. 

The visible components of the resulting physical 
database structure are the stored record format, stored 
record placement specification, and access i'>ethod 
specification. Underlying these specifications is the 
satisfaction of all operational requirements and 
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hardware/software system constraints. During the design 

process, consideration of efficiency issues can take place 
only after the various constraints are satisfied and a 
feasible solution has been obtained. 

2 • ce tJea sure 

The determination of performance measures for 
physical design is most critical to the design process. It 
affects not only the design choices, but also the 

techniques employed to determine those choices. 

Let us assume that database system performance 

will be described in terms of cost. At various times cost 

may be given in terms of time, space, or possibly monetary 
value. Returning to our discussion of the database system 

life cycle, we can describe the total cost of the life cycle 
in terms of the following: 

* Planning cost 

* Design cost : programs, database 

* Implementation and testing cost : programs, databases 

* Operational costs : users, compute resource 

* Maintenance costs : program errors, data integrity 

loss 

3 . Outputs of Physical Design 

In general, two major specifications are produced. 
First, the physical specification of the logical schema is 
defined. It is the physical schema. This schema is a 
transformation of the logical schema into the data modeling 
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constructs availalle with the DFMS to he used. Second, user 
views are defined. 

a. Physical schema 

The contents of records must be defined, and 
the name and format of each field of each record specified. 
Constraints from the logical database design are tranformed 
into critiria for field descriptions. Keys of database 
records need to be identified, and overhead structures for 
supporting the keys defined. Record relationships are also 
defined in the physical design. 

b. User views 

User views are generally a subset of the 
schema. Records or relationships may be omitted from a view; 
fields may be omitted or rearranged. Also, the names of 
records, fields, or relationships may be changed. This 
flexibility allows users to employ terminology that is 
familiar and useful to them. 

C. APPLICATION OP DATABASE MODELS TO DATABASE DESIGN 

Figure 3.5 shows the major steps involved in 
designing a database. Inputs to design are statements of 
data requirements from the specification data directory. The 
output of design is a specification that can be used to 
implement the database using a commercial DBMS. The design 
that is produced depends very much on the CRMS to be 
employed. For this reason. Figure 3.5 shows two alternative 
design outputs. If we are going to \ise a DBMS based on the 
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relational model, we will produce a relational design. If 
we are going to use a DBMS based on the CODASYL B3TG model, 
we will produce a DBTG( network) design. 

Within this figure are two steps : logicaKDSMS 
independent) design and physical (DBMS - dependent) design. 
After logical design, there is a branch, depending on the 
DBMS to be employed. If we are going to use a relational 
DBMS, then the output of physical design will be a 
relational design expressed as relation definitions and 
supporting documentation. 

If we are going to use a CODASYL DBMS, then the output 
of the physical design will be a CODASYL design expressed as 
data structure diagrams and supporting definitions. 



User requirement 



Specification 1 



Logical Design 



1 SDM Form of 1 
1 Logical Schema | 



j > 1 Relation Definition and 

I 1 Supporting Documentation 

I 

I 



Physical design 



OR 



Relational 

DBMS 



I > 



Data Structure diagram 
and supporting 
Documentat i on 



CODASYL 

DBTG 

Da taba se 



Figure 3.5 Use of Model in Database Design 



33 



IV. SEMANTIC DATABASE MODEL 



The Semantic Database Model(SDM) was developed by 
Hammer and McLed [Ref. 8] and first published in 1981. It 
will be used as the tool for expressin a logical schema for 
the Intelligence database design. 

SDM is a high-level semantics-based database 
description and structuring formalism for the database. This 
database model is designed to capture more of the meaning of 
an application environment than is possible with 
contemporary database models. 

SDM is designed to enhance the effectiveness and 
usability of database systems. An SD^^ database descriition 
can serve as a formal specification and documentation tool 
for a database. It can provide a basis for supporting a 
variety of powerful user interface facilities, serve as a 
conceptual database model in the database design process, 
and be used as the database model for a new kind of database 
management system. 

A. INTRODUCTION 

Every database is a model of some real world system. At 
all times, the contents of a database are intended to 
represent a snapshot of the state of an application 
environment, and each change to the database should reflect 
an event occuring in that environment. Therefore, it is 
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appropriate that the structure of a database mirror the 
structure of the system that it models. K database whose 
organization is based on naturally occurring structure will 
be easier for a database designer to construct and modify 
than one that forces him to translate the primitives of his 
problem domain into artificial specification constructs. 

The global user view of a database, as specified by the 
database designer, is known as its logical schema. A schema 
is specified in terms of a database description and 
structuring formalism and associated operations, called a 
database model. It was thought that the data structures 
provided by contemporary database models do not adequately 
support the design, evolution, and use of a complex 
database. These database models have signi f i cant ly limited 
capabilities for expressing the meaning of a database and 
relating a database to its corresponding applicatian 
environment. The semantics of a database defined in terms 
of these mechanisms are not readily apparent from the 
schema; Instead, the semantics must be separately specified 
by the database designer and consciously applied by the 
user . 

The goal is the design of a higher-level database model 
that will enable the database designer to naturally and 
directly incorporate more of the semantics of a database 
into its schema. Such a semantics-based database description 
and structuring formalism is intended to serve as a natural 
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application modeling mechanism to capture and express the 
structure of the application environment in the structure of 
the database. 

1 • I&e Design of SDM 

In designing SDM, many database aplications were 
analyzed in order to determine the structures that occur 
and recur in t hem . The shortcomings of contemporary 
database models in capturing the semantics of these 
applications were assessed, and the strategies were 
developed to address the problems discovered. This design 
process was iterative, in that features were removed, added, 
and modified during various stages of esign. 

SDM has been designed with a number of specific 
types of uses in mind. First, SD^’ is meant to serve as a 
formal specification mechanism for describing the meaning of 
a database; SDM provides a precise documentation and 
communication medium for database users. In particular, a 
new user of a large and complex database should find its SDM 
schema of use in determining what information is contained 
in the database. Second, SDM provides the basis for a 
variety of high-level semantics-based user interfaces tc a 
database; these interface facilities can be constructed as 
front-ends to existing database management systems. 

SDM has been designed to satisfy a number of 
criteria that are not met by contemporary database models. 
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but which I believe to be essential in an effective database 
description and structuring formalism. They are as follows. 

The constructs of the database model should provide 
for the explicit specification of a large portion of the 
meaning of a database. Many contemporary database models 
(such as the COLASYL DBTG network model and the hierachical 
model) exhibit compromises between the desire to provide a 
user-oriented database organization and the need to support 
efficient database storage and manipulation facilities. In 
contrast, the relational database model stresses the 
separartion of user-level database specification and 
underlying implementation detail. 

However, the Semantic expressiveness of the 
hierachical, network, and relational model is limited; they 
do not provide sufficient mechanism to allow a database 
schema to describe the meaning of a database. Such models 
employ overly simple data structures to model an application 
environment. In so doing, they lose information about the 
database; they provide for the expression of only a limited 
range of a designer's knowledge of the application 
environment. It is necessary to break with the tradition of 
record-based modeling and to base a database model on 
structual constructs that are highly user oriented and 
expressive of the application environment. 

A database model must support a relativist view of 
the meaning of a database, and allow the structure of e 
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database to support alternative ways of looking at the same 
information. In order to accommodate multiple views of the 
same data and to enable the evolution of new perspectives on 
the data, a database model must support schema that are 
flexible, potentially logically redundant, and integrated. 
Flexibility is essential in order to allow for multiple and 
coequal views of the data. 

C ont empor ary , record-oriented database models do 
not adequately support relativism. In these models, it is 
generally necessary to impose a single structural 
organization of the data, one which inevitably carries along 
with it a particular interpretation of the data's r.eaniag. 
This meaning may not be appropriate for all users of the 
database and may become entirely obsolete over time. 

Another consequence of the primacy of the 
principle of relativism is that, in general, the database 
model should not make rigid distinctions between such 
concepts as entity, association, and attribute. Higher-level 
database models that do require the database schema 
designers to sharply distinguish among these concepts are 
thus considered somewhat lacking in their support of 
relat iv ism. 

A database model must support the definition of 
schemata that are based on abstraction entities. 
Specifically, this means that a database model must 
facilitate the description of relevant entities in the 
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application envi ronrren t , collections of such entities, 
relationships among entities, and structual inter- 
collections among the collections. 

Allowing entities to represent themselves makes it 
possible to directly reference an entity from a related one. 
In record-oriented database models, it is necessarv to cross 
reference between related entities by means of their 
identifiers. While it is of course necessary to eventually 
represent 'abstract' entities as symbols inside a computer, 
the point is that users should be able to reference and 
manipulate abstractions as well as symbols. 

B. A SPECIFICATION OF SDM 

The following general principles of database 
organization underlie the design of SDM [Ref. 3 ]. 

(1) A database is to be viewed as a collection of entities 

that correspond to the actual objects in the 

application environment 

(2) The entities of a database are organized into CLASSES 
that are meaningful collections of entities. 

(3) The classes of a da ta base are not in general 

independent, but rather are logically related by means 
of Interclass connections. 

(4) Database entities and classes have ATTIHIEUTFS that 
describe their characteristics and relate them to 
other database entities. An attribute value may be 
derived from other values in the database. 
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(5) There are several primitive ways of finding interclass 
connections and derived attributes, corresponding to 
the most common types of information redundancy 
appearing in database applications. These facilities 
integrate multiple ways of viewing the same basic 
information . 

1 2t §5 SDM Entity Class 

The basic format of an SEI^ entity class 
description is given in Figure 4.1. [Ref. 3] 



ENTITY-CLASS-NAME 

[description ] 

[interclass connection ] 

member attributp : 

At tribute-name 

value class : 

[mandat ory ] 

[multivalued] [no overlap in values] 
[exhaust value class] [not changeable] 
[inverse : Attribute-name] 

[match : Attribute-name 

ENTITY - CLASS on At t ri bu t e-nan:e2] 



[derivation : ] 

[ class attribute : 

Attribute-name 

[description : ] 

value class : : 

[derivation : ]] 



identifier : attribute-name + [At t r i but e-name2 + [ ]]] 



Figure 4.1 Format of SDM Entity Class Description 



40 



C* SDM POR INTELLIGENCE DATABASE 

Figure 4.2, Figure 4.3, Figure 4.4, Figure 4.5 show a 
SDM logical schema for the Intelligence Datsahase. The data 
given in Appendix A to be used is composed of four records; 
First, Installation records which describe the normal Master 
file of Installation includes several fields such as Iclass, 
lid, larea, Ipers, Iff, I class/Itype. Second, Arimuniticn 
records which describe all information about Ammunition 
include several fields such as Acat, Albs, Akill, Awar. 
Third, Photo records which describe all information of Photo 
taken includes several fields such as Pday, Pii, 
Pclass/Ptype, Pnum, Pwc. Finally Weapon records which have 

all information of Weapons include fields such as Wclass, 
Wtype, Wff, Wammo, Wrange, Wfeul, Vlbs. INSTALLATION is 
first defined. The class is named, and then an informal 
description of the class is provided. The description, which 
is optional, defines the purpose and content of the class. 
Special remarks are written here. Next, the member 
attributes are defined. These are attributes of the entities 
in this class. According to the Photo days in Photo record. 
Installation records are updated, so Iclass/Itype has Match 
function; Match : PCLASS/PTYPE of PEEC on PIT. And 
Ammunition and Weapon records are automa tica lly updated. 
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INSTALLATION 



description : the basic master file for 

installation representing all informations 

about installation such as Installation 

Class, Id code, Area and their physical 

and tactical characteristics. 

member-attribute : 

Iclass 

Description : Installation class 
Value class '• INS-CLASS 
Mandatory 
Not changeable 

lid 

Description ; Installation 

Iden tif ica ti on 
Value class : INS-ID 
Mandatory 
Not changeable 

larea 

Description ; Estimated Area 
Value class : AREA 

Iper s 

description : Estimated persons 
Value class : NO-OE-PERSONS 

Iff 

Value class : FP lEND-OE-FOE 
Iclass/I type 

description : Concatenation of 

weapon class and type 
Value class : PREC 

Match : PCLASS/PTYPE of PREC on PID 
'Cond2': Multivalued 

Not changeable 

Class attribute : 

Total-foe 

description : total foe numbers 

Valu-e class : TCTAL-NUMPEE 

Identifier : lid 



Figure 4.2 SDM of IREC in the Intellience Database 
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PREC 



I 



description : information about the 

reconnaissance date, weapons observed 
weather condition 
Member attributes : 



Pday 

descripti on 

on which 
Value class : 

Pid 

description : 
Value class : 
Mandatory 

Pda ss/type 

dscription : 
weapon 
Value class : 



Multivalued 

Pnum 

description : 
Value class : 

Pwc 

description : 
Value class : 
Mandatory 

Idenfitier : Pday + Pid 



the day of the 
the photo taken 
DATE 



Installation Id c 
INS-ID 



Concatenation of 
class and type 
Weapon-class / 
weapon-type 



observed weapons 
NUM-OF-VEP 



Weather condition 
WEATHER 



+ Pclass/type 



and 



year 



od e 



Figure 4.3 SDM of PREC in the Intelligence Database 



AREC 



description : Anrro categories and their 

physical characterics 
Member attribute : 

Acat 



description : Ammo category 
Value class : AMMO-CATEGORY 
Mandatory 
Not changeable 

Wher e-needed 

description ; What kind of 

Weapon class/type needed 
for this Ammo category 

Albs 



description : Weight of 1 round of 
Ammo 

Value class : MAX-load 

Mandatory 

Not changeable 

Akill 

description : Killing radius 

of Ammo 

Value class : RANGE 

Awar 

description : Type of warhead 
of Ammo 

Value class : WARHEAD-CAT 
Identifier : Acat 



Figure 4.4 SDM of AREC in the Intelligence Database 
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WREC 



I 



description ; all information related to 
weapon class/type and their physical 



characteristics . 



Member attribute : 

W class 

Value class : WEAPON-CLASS 
Mandatory 

Vtype 

description : Weapon Type 
Value class : WEAPON-TYPE 
Mandatory 



Wf f 

description ; whether the weapon 

is Eriend or Eoe 
Value class : WREC 

Wammo 

description ; What sort of Ammo 

can be available for particular 
type of weapons 
Value class : AREC 
Inverse : Wclass/Type-Needed 
Multivalued 



Wr ange 

description : Weapon range 
Value class : RANGE 

Wf uel 

description : Euel capacity 

of weapon 

Value class : EUEL-CAP 



VI bs 

description : Maximum Load 
Value class : MAX-LOAD 
not changeable 



identifier ; Wclass + Wtype 



Figure 4.5 SEM of WREC in the Intelligence Database 
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WEAPON-CLASS : subclass of STRINGS where value is 

AC, SH, ARU 

WEAPON-TYPE : subclass of SRTIN S where value 
is positive single digit integer 1,2, 3, 4, 5, 6 
RANGE : subclass of STRINGS where value is 

positive integer less than 100,000 
FUEL-CAPACITY : subclass of STRINGS where value 

is positive integer less than 20,0O0 
MAX-LOAD : subclass of STRINGS where value if 

positive integer less than 500,000 
DATE : Subclass of STRINGS where value is 

positive integer between 1...365 
INS-CLASS ; subclass of STRINGS where format 
is 2 characters: AE , PO, AR 

INS-ID : format is 3 digit positive integer 
AREA : value is in between 1...100 
N0-OF-PERSON : value is less than 10,000 
FRIEND-OR-FOE : formats are FED, FOE 
NUM-OE-WEAPON : format is positive integer 
WEATHER : value is FAIR, CLDY or PCLDY 
ammo-cat : value is single letter 
RRANGE : value is positive integer 
Warhead : value is positive integer 1...10 



Figure 4.6 Domain of Attribute 
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D. ATTRIBUTE 

In Figure 4.6 above, each class has an associated 
collection of attributes. Fach attribute has the follov/ing 
f ea tures . 

(1) An attribute name identifies the attribute. An 
attribute must be unique with respect to the set of 
all attribute names used in the class, the class's 
underlying base class, and all eventual subclass of 
that the base class (e.g., Iclass, lid^ in IFF.C 
(Figure 4.2). 

(2) The attribute has a value which is either an entity in 
the database or a collection of such entities. The 
value of an attribute is selected from its underlying 
value class, which contains the permissible values of 
the attribute. The value of an attribute may also be 
the special value NULL. (e.g., INS-CLASS, INS-ID) in 
IP.EC (Figure 4.2) . 

(3) The APPLICABILITY of the attribute is specified by 
indicating that the attribute is either: 

(a) a member attribute. which applies to each 
member of the class, and so has a value for 
each member (e.g., Iclass of IFFC ) (Figure 
4.2) 

(b) a class attribute, which applies to a class 
as a whole, and has only one value for the 
class (e.g.,Idate of IREC) 
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(4) An (optional) ATTRIBUTE DESCRIPTION is text that 
describes the meaning and purpose of the attribute. 

(5) The attribute is specified as either SINGLE VALUED or 
MULTIVALUED. The value of a single-valued attribute is 
a member of the value class of the attribute, while 
the value of a multivalued attribute is a subclass of 
the value, (e.g., Pclass/type has Multi-value) 

(6) An attribute can be specified as MANDATORY, which 
means that a null value is not allowed for it. (e.g., 
Ic lass ) 

(7) An attribute can be sp<=cified as not changeable, which 
means that once set to a nonnull value, this value 
cannot be altered except to correct an error. (e.g., 
I class ) 

(8) A member attribute can be required to be EXHAUSTIVE of 
its value class. This means that every member of- the 
value class of the attribute must be the value of some 
entity. 

(9) A multivalued member attribute can be specified as 
NONOVERLAPPING, which means that the values of the 
attribute for two different entities have no entities 
in common. 

1 . Member Attribute Interrelationships 
a. Inversion 

The first way in which a pair of member 
attributes can be related is by means of INVEFSION. ^'ember 
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attribute A1 of class Cl can be specified as the inverse of 
member attribute A2 of C2 which means that the value of M 
for a member Ml of Cl consists of those members of C2 whose 
value of A2 is i^l. The inversion interattribute relationship 
is specified symmetrically in that both an attribute end its 
inverse contain a description of the inversion 
relationship. A pair of inverse attributes in effect 
establish a binary association between the members of the 
classes that the attributes modify. For example, V/ammo in 

WREC record has inverse relationship with Where-needed in 
AEEC record. 

Therefore, value class and inverse is defined 

in Wammo and another item name is defined in AEEC record, 
which corresponds to Wammo item name. 

b. Matching 

The second way in which a member attribute 
can be related to other information in the databas'^ is by 
matching the value of the attribute with some miernber of a 
specified class. In particular, the value of the match 
attribute A1 for the member Ml of class Cl is determined as 
follows . 

(1) A member M2 of some class C2 is found that has Ml as 
its value of member attribute A2. 

(2) The value of member attribute A3 for M2 is used as the 
value of A1 for Ml. 
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If A1 is e multivalued attritute, then it is 
permissible for each member of Cl to match to several 
members of C2; in this case, the collection of A3 values is 
the value of attribute Al. For example, Iclass/Itype is 
matched with Pclass/Ptype (Figure 4.3). 

Therefore, match is defined only in IRIC 
record and not defined in PP.EC record. That means, according 
to PID, Pclass/Ptype is matched and the value is updated. 

Inversion and matching provide multiple ways 
of viewing n-ary associations among entities. Inversion 
permits the specification of binary associations, while 
matching is capable of supporting binary and higher degree 
associations. 

c. Derivation 

Inversion and matching are mechanisms for 
eastablishing the equivalence of different ways of viewing 
the same essential relationships among entities. SD^' also 
provides the ability to define an attribute whose value is 
calculated from other information in the database. Such an 
attribute is called Derived, and the specification of its 
computation is its associated derivation. 

The approach is to provide a small vocabi'.lary 
of high-level attribute derivation primitives that directly 
model the most common types of derived information. Each of 
these primitives provides a way of specifying one method of 
computing a derived attribute. More general facilities are 
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available for describing attributes that d not match any of 
these cases. For example, Total-foe is derived from IREC 
record by calculating total number of foes. 

2» Class Attribute In terrelaiioniJiiES 

Attribute derivation primitives analogous to 
primitives for member attributes can be used to define 
derived class attributes, as these primitives derive 
attribute values from those of other attributes. In 
addition, there are two other primitives that can be used in 
the definition of derived class attributes. 

(1) An attribute can be defined so that its value 
equals the number of members in the class it modifies. For 
example. Total-foe has the derivation 'number of members in 
this class'. 

(2) an attribute can be defined whose value is a 
function of a numeric member attribute of a class; the 
functions supported are 'maximum', 'minimum', 'average'. 

D. APPLICATION 

SDM is simply an abstract database modeling mechanism 
and language that is not dependent on any supporting 
computer system. One set of applications uses SDK in 
precisely this mode to support the process of defining and 
designing a database as well as in facilitating its 
subsequent evolution. It is well known that the process of 
logical database design, wherein the DBA must construct a 
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schema using the datatase model of the DBNS to be employed, 
is a difficult and error-prone procedure. A primary reason 
for this difficulty is the gap between the semantic level of 
the application and the data structures of the database 
model; the DBA must bridge this gap in a single step, 
simultaneously conducting an information requirements 
analysis and expressing the results of his analysis in terms 
of the database model. 

1 • The Advan tage Of SDM 

An SDM schema will serve as a specification of the 
information that the database will contain. All too often, 
only the most vague and amorphous English language 
descriptions of a database exist prior to the database 
design process. A formal specification can more accurately, 
completely, and consistently communicate to the actual 
designer the prescribed contents of the database. SIM 
provides some structure for the logical database design 
process. The DBA can first seek to describe the database ir. 
high-level semantic terms, and then reduce that schema to a 
more conventional logical design. 

SDM supports a basic methodology that can guide 
the DBA in the design process by providing him with a set of 
natural design templates. That is, the DBA can approach the 
application in question with the intent of identifying its 
classes, subclasses, and so on. Having done so, he can 
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select representations for these constructs in a routine, if 
not algorithmic, fashion. 

SDM provides an effective base for accommcda t ing 
the evolution of the content structure and use of a 
database. Relativism, logical redundancy, and derived 
infomation support this natural evolution of the schema. 

A related use of SDM is as a medium for 
documenting a database. One of the more serious problems 
facing a novice user of a large database is determining the 
information content of the database and locating in the 
schema the information of use to him. An SDM schema for a 
database can serve as a readable description of its 

contents, organized in terms that a user is likely to be 
able to comprehend and identify. 
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V. RELATIONAL DATABASE DESIGN 



A. INTRODUCTION 

The relational model was first proposed ty Dr. E. ?. 
Codd in a seminal paper in 1970 [Ref. 13]. This innovation 
stressed the independence of the relational representation 
from physical computer implementation such as ordering on 
physical devices, indexing, and using physical access paths. 
The model thus formalized the separation of the user view of 
data from its eventual implementation; it was the first 
model to do so. In addition, Codd proposed criteria for 
logically structuring relational databases and an 
implementation-independent language to operate on these 
databases. The relational model represents data in the 
simple form of tables. The relational model is attractive 
in database design because it provides formal criteria for 
logical structure, namely, normal form relations. 

1 • Termino lo gy 

A relation is simply a two-dimensional table that 
has several properties. First, the entries in the table are 
single-valued; neither repeating groups nor arrays are 
allowed. Relations are flat files. Columns of a relation are 
refered to as attributes. Each row of the relation is known 
as a tuple. If the relation has n columns, then each row is 
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refered to as an n-tuple. Also, a relation that has n 
columns or n attributes is said to be of degree n. 

2* Igl^tion 

This key is the attribute or set of attributes 
that uniquely identifies tuples in a relation. A relation 
key is formally defined as a set of one or more relation 
attributes concatenated so that the following three 

properties hold for all time and for any instance of the 
relation: 

1. Uniqueness : The set of attributes takes on a unique 

value in the relation for each tuple. 

2. Nonredund ency : If an attribute is removed from the 

set of attributes, the remaining attributes do not 
posses the uniqueness property. 

3. Validity : No attribute value in the key may be null. 

When two or more attributes or attribute 

collections can be keys, they are called candidate keys. 
When one of the candidates is selected to be the key, it is 
called the printary key. When an attribute in one relation 
is a key of another relation, the attribute is called a 
foreign key. Foreign keys are important when defining 
constraints across relations. 

3 • Relational Algebra 

The relational algebra consists of a set of 

relational algebra operators. Each operator has one or more 
relations as its input and produces a relation as its 
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output. The three basic relational algebra operations are 
SELECTION, PROJECTION, and JOINING. 

The SELECTION operator selects all tuples frorr 
some relation such that some attributes in each tuple 
satisfies sotne condition, k new relation, which contains the 
selected tuples, is then created. 

The PROJECTION operator constructs a new relation 
from some existing relation by selecting only attributes of 
the existing relation end eliminating duplicate tuples in 
the newly formed relation. 

The JOINING is a met hod of combining two or more 
relations into a single relation. At the outset it requires 
the choice of attributes to match tuples in the relations. 
Tuples in different relations, but with the same value of 
matching attributes, are combined into a single tuple in the 
output relation. The examples of using three basic 
operators will be shown in Chapter IV. 

B. RELATIONAL NORMAL FORMS 

Not all relational database designs are equal; some are 
better than others. Obviously, a design that meets the 
users'needs is better than one that does not, but there are 
other criteria as well. With some relations, changing data 
can have unexpected consequences. These consequences, called 
modification anomalies, are undesirable. These anomalies can 
be eliminated by changing the database design. Usually 
relations without modification anomalies are prefered. Some 
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relations are independent, others are interdependent. 
Generally, hut not always, the less interdependency, the 
better. 

1 • Molificat i on Anorna lies 

Consider Ammunition relation in Figure 5.1. It 
has the attributes ACAT, ALBS, AKILL, and AWAR. The meaning 
of a tuple is that given an Ammo category. Weight of Cne 
round and Killing Radius and Warhead Category are 
determined . 

For the data in Figure 5.1, if we delete the 
tuple for ACAT A, we will lose not only the fact that Ammo 
Category k's Weight is 410 lbs, but also the fact that 
Killing radius is 120 feet. This is called a DFLFTION 
AiVOMALYI we may be losing more information than desired. We 
lose facts about three attributes with one deletion. This 
characteristic may be considered undesirable because it is 
usually unintended. 



AMMUN'IT ION 
Key : ACAT 
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Figure 5.1 The Ammunition Relation 
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Also, suppose we want to enter the fact that ACAT 
E has a killing radius of 525 feet. '*’e can not enter this 
data into the Ammunition relation until a ACAT has ALES and 
AWA?-. This restriction seems unnecessary. This situation is 
called an Insertion Anomaly. Ve gain facts atout three 
attributes with one insertion; or, stated negatively, we 
cannot insert a fact about one attribute until we have an 
additional fact about another attribute. These an omal ies 
can be eliminated by the creating two new relations via 
projection. An example of this will be shown in Figure 5.9. 

2* Classes of Modification Anomalies 

There are many different types of modification 
anomalies. In the 1970s relational theorists chipped away at 
these types. Someone would find an anomaly, classify it, and 
think of a way to prevent it. This process generated 
improved criteria for designing relations. These criteria 
are called Normal Forms. 

Codd, in his paper [Ref. 13] defined first, 
second, and third normal forms. Later, Boyce-Codd normal 
form was postulated, and then fourth and fifth normal forms 
were defined. As seen in Figure 5.2, each of these 
normal forms contains the other. A relation in fifth normal 
form is aut oma t i cal ly in 1, 2, 3, BC, and 4 normal forms. 
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— INF 

— ?NF 

— 3NF 

— FCNF 

— 4NF 

— 5NF 



- TK/NF 



Figure 5.2 Relationship of Normal Forms 



These normal forms were helpful, lut they had a 
serious limitations. No theorist was able to guarantee that 
any of these forms would eliminate all anomalies? each form 
would eliminate just certain anomalies. This situation 
changed, however, in 1961 when R.Fagin defined a new normal 
form called DOMAIN/KEY normal form(DK/NF). Fagin showed that 
a relation in domain/key normal form is free of all 
modification anomalies, regardless of their types. 

Until DfC/NF was identified, it was necessary for 
relational database designers to continue looking for 
more and more anomalies, and more and more normal forms. 
Fagin's proof, however, greatly simplified the situation. 
If we can put a relation in DK/NF, then we are guaranteed it 
will have no anor^alies. 



3. Kinds of Normal Form^ 

All relations are in first normal form. A relation 
is in first normal form if and only if all underlying 
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domains contain atomaic values only. Relations in first 
normal form have modification anomalies. It is possible to 
eliminate some of these anomalies hy putting the relation in 
second normal form. Ve can eliminate even more when the 
relation is put in third normal form, and even more with 
Boyce-Codd normal form. 

A functional dependency (FD) [Ref. 6] is a term 
derived from mathematical theory; it concerns the dependency 
of values of one attribute or set of attributes on those of 
another attribute or set of attributes. Formally, a set of 
attributes X is functionally dependent on a set of 
attributes Y if a given set of values for each attribute in 
Y determines a unique value for the set of attributes in X. 
The notation Y — > X is often used to denote that X is 
functionally dependent on Y. The att ibutes in Y are known 
as the determiinant of the functional dependency Y — > X. 

A relation is in second normal form if and only if 
it is in IMF and every nonkey attribute is fully dependent 
on the primary key. 

A relation is third normal form if it has the 
following properties: (1) The relation is in second normal 
form. (2) Every nonkey attribute is nont rans i t i ve ly 
dependent on the primary key. 

A relation is in BCMF if every determinant is a 
candidate key. Since relations in BCNF have no anomalies 
regarding functional dependenies, this seemed to put the 
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issue of modification anomalies to rest. However. it was 
soon discovered that anomalies can arise from situations 
other than functional dependencies. 





Formally, multivalued 


dependency 


i s 


ief L ned 


d S 


follows; 


In relation R(X,Y,Z), 


X ==> Y 


if 


each 


X va lue 


is 


associated 


with a set of Y values in a 


way 


tha t 


d oes 


not 



depend on the Z values. 





A 


relation is in 


fourth normal form [Sef. 6] if 


i t 


is in 


BCNF 


and has no 


multivalued dependencies. T 


^ i s 


def i ni t i on 


means that 


if a relation 


has multivalued 


dependencies 


and is in 


fourth normal 


form, then 


the 


mul tiva lued 


d ependencies 


have a single 


value. In ot 


h e r 


words , 


all 


independent 


attributes have 


a single value. 




A 


relation is in 


fifth normal for 


■m i f and only 


if 


eve ry 


join 


dependency in a relation is 


implied by 


the 



candidate keys of the relation. 

A relation is in DK/N? if every constraint on the 
relation is a logical consequence of the definition of keys 
and domains. A constraint is any ri;le on static value-^ of 
attributes that is precise enough that we can evaluate 
whether or not it is true. Thus intra- and inter-relation 
constraints, functional dependencies, multivalued 
dependencies, and join dependencies are all examples cf 
constraints. DK/NF means that if we can find a way to 
define keys and domains such that all constraints will be 
satisfied when the key and domain definitions are satisfied. 
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then TiOd if ication anomalies are impossible. Unfortunately, 
there is no known way to convert a relation to EK/N? 
automatically, nor is it even known which relations can be 
converted to DK/NF. In spite of this, DK/N7 can be 
exceedingly useful for practical database design. 

C. RELATIONAL DATABASE DESIGN CRITERIA 

Berri and co-workers [Ref. 9] have identified three 
relational criteria; 

(1) Representation : The final structure must correctly 
represent the original specification. 

(2) Separation : The original specifications are divided 

into relations that satisfy certain conditions. 

(2) Redundancy : The final structure must not contain 

any redundant 1 n^’orma t i o n . 

First of all, the database must be separated into a 
number of normal form relations. The other two criteria are 
relatively general. In speific terms each can be applied to 
attributes, functional dependencies or data. To determine 
the criteria more specifically, notation for a relation and 
the input and output of a design process is needed. 

A relation is defined as made up of two components, the 
attribute and the functional dependenci es( FC ) between the 
attributes. The definition takes the form 

R = ({A,B,C}, {A ==>B, A ==> C}) 

Here R comprises three attributes. A, E, and C. The FTs 
between these attributes are A ==> E and A ==> C. The 
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notation used to describe the input and output of the design 
process is Sin and Sout. Both Sin and Sout is are sets of 
relations. Here Sin is the input to the design process and 
Sout is the output. Most theoretical work is based on the' 
universal relation assumption and assume that Sin is one 
relation, the universal relation, which is defined by a set 
of attributes and FDs, i-ising the preceding notation, and 
that Sout is a set of normal relations, each of which is 
made up of a set of attributes and a set of ?Zs. 

1 Etpresenta t ion Criteria 

One goal of any design process is to produce an 
output design, Sout, to accurately represent Sin. Further, 
all the relations in Sout must satisfy the conditions for 
normal form. C.Berri and co-worl-cers ( 1978 ) [Ref. 9] have 
defined three representation criteria for the representation 
of Sin by Sout : 

REPl : The relation Sout contains the same 

attributes as Sin. 

* REP2 : The relation Sout contains the same attributes 

and the same FDs as Sin. 

* REP3 : The relations in Sout contain the same 

attributes and the same data as Sin. 

REPl is trivial. It requires all the attributes in 
Sin to also apppear in the relations in Sout. But it does 
not consider any dependencies between the attributes. 



^3 



In regard tc RI?2, recall that Sin is defined as a 



set of attributes and FEs and that each relation in Sout 
will also contain a set of attributes and a set of FEs. 
representation PEP2 requires that each FD in Sin be either 
contained as an FD in one of the relations in Sout or 
* derived from the FDs in the relations in Sout, using 
the FD inference rules. 

For example, in Figure 5.3, Sin = ({A,B,G}, {A 
==> B, C ==> B}), Sout = (P2,R3) where R2 = ({^,B}, {A ==> 
3}) and E3 = ({B,C}, {C ==> B}). Thus R2 and R3 constitute 
the decomposition by projection of Sin. 
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Figure 5.3 
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2. Lossless Decorn£osi t i ons 

Formally, a lossless decomposition can le 
described as follows. The decomposition of a relation 
R(X,Y,Z) into R1 and E2 is defined by two projections: 

" R1 = projection of R over X,T 
*1* R2 = projection of R over X,Z 
where X is the set of common attributes in R1 and R2 . The 
decomposition is lossless if R = join of Rl, R2 over X. The 
composition is lossy if R C join of R1,R2 over X. 

3* Critera 

Redundancy criteria can be defined in various 
ways. One way of defining redundancy criteria is as follows: 
REDl : A relation in Sout is redundant if its 

attributes are contained in the other relations in Sout. 

* RED2 : A relation in Sout is redundant if its FDs are 

the same or can be derived from the FDs in the' other 
relations in Sout. 

* RED3 : A relation in Sout is redundant if its content 

can be derived from the contents of other relations in 
S out . 

Obviously, RECl is not a very useful criterion, 
because during separation it is often necessary to create 
separate relations that represent FDs between attributes, 
which may appear in other relations. On the other hand, RED2 
and RID3 can be quite useful criteria. Any design 
algorithms should in particular avoid RED3, because it 
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would keep tbe same data iu more than one relation. Such 
relations could all he in normal form and no anomalies would 
occur in relations. However, in t er r ela t i onal a omalies would 
arise if some fact were updated in one relation hut the 
other. Desigrus that include REDS would cause the same 
pro hi em . 

of tJodif icat Ipn Anomalies 

If relations can he put into EK/NF, then no 
modification anomalies can occur. Thus D.K/.MF becomes a 
design objective, and relations that are in DK/KF are 
usually preferred. 

Not all relations, however, can he put into DK/NF. 
This occurs when there are constraints that cannot he 
expressed as logical consequences of keys and domains. As 
example described by Fagin [Ref. 14] is a relation having 
the following constraints: The relation must never have 
fewer than three tuples. There is no way to express this 
constraint in terms of domains and keys. Thus it has a 
modification anomaly. In fact, this strange relation has a 
deletion anomaly hut no insertion anomaly. 

When relations cannot he tranformed into EX/NF, 
the constraint that cannot he expressed in terms of domains 
and keys must he inserted into application programs. This is 
undesirable because the constraint is hidden. 
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5 • 5§.i§ of ni§ 

A fifth criterion for a relational design is ease 
of use. As far as possible, we strive to structure the 
relations so that they are familiar and seem natural to 
users. Sometimes this goal conflicts with the elimination of 
anomalies or with independence. 

D. RELATIONAL DATABASE MANAGEMENT SYSTEM 

This section [Ref. 3] describes the relational model as 
the implementation model that is supported by a DE^^S . Any 
relations produced during data analysis can be implemented 
directly on this DBMS. Because of its tabular interface, 
the relational model makes an attractive implememtaion 
model. It is receptive to two types of environments t 

the traditional data processing environment, in which 
databases are set up by professional computer 
programmers on behalf of database users. 

* environments in which nonprogrammer users set up their 
own databases. 

The relational model provides the same advantages in 
both types of environments. Its natural interface simplifies 
the design and use of the database. This is particularly so 
if a language with powerful selective capabilities can be 
provided by the DBt'S. Such languages can reduce program 
development time and hence are attractive in commercial 
data-process ing environments. They are also attractive to 
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nonpr cgramner users, allowing then to use the datehase 
without resorting to computer-oriented procedual languages. 

1 . Characteristics 

What characteristics must a DBMS have to he 
considered a relational product? In his Turing lecture, 

E.F Codd [Ref. 15] defined a relational DBMS as one in 

which data is defined in tables and processed ty using 

SELECT, PROJECT and unrestricted JOIN operations, or their 

equivalent. Codd called a system having these 

characteristics MINIMALLY RELATIONAL. 

SELECT, PRODUCT, and JOIN will he used in Chapter 
VI. The SELECT obtains rows of the table according to 
criteria on row contents. PROJECT obtains columns of a table 
by column name. Finally, JOIN brings two relations together 
based on the relationship between two columns having the 
same domain. 

Some DBMS products specify that only columns can 
be used as JOIN criteria. For example, a DBMS may require 
the columns used as JOIN criteria to be indexed. This 
implies the undesirable situation of restricting user 
activity because of physical data re resentation. To the 
nonspecialist user, this restriction appears arbitrary. In 
fact, there is no logical reason for this restriction; it 
exists only to improve performance. To eliminate this 
situation, Codd specifies that a minimally relational system 
must have unrestricted JOINS. This means that any column can 
be used as criteria for the JOIN. 
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2. Commercial Relational DBMS 

There are currently many commercial EEMS products 
that claim to he relational. Some are more relational in 
name than in actuality. Criteria can be used to assess 
whether or not a product is truly a relational product. 
Specially, the DBMS should model data as tables, and it 

should support SELECT, PROJECT, and unrestricted JOIN 

operati ons . 

Relational DBMS can be divided into three groups. 
One group is based on the data language SQL, one on the data 
language QUEL, and a group that contains systems falling 

into neither of these categories. 

Three major SQL-based DBMS products are SQL/DS, 
System R, and ORACLE. System R is a research system 

developed by IBM for the study of relational technology. 
ORACLE is vended _by Relational Software Incorporated. 
Originally, ORACLE was developed for operation on Digital 
Equipment Corporation ?DP minicomputers. Since its origin, 
ORACLE has teen converted to operate on IBM mainframes as 
well. Oracle's user interface is based on SEQUEL II, an 

earlier version of SQL. According to RSI, ORACLE will soon 
be compatible with the current version of SQL. QUEL is a 
data language like SQL. (Just like COBOL and PL/I are 
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user to process data without concern for physical data 

structures . 

There ere many other relational DBMS. Figure 5.4 

lists some of the major systems as of late 19S2. There is 

also a microcomputer relatione] product: dBASF II, which 

operates on CP/M-based micro. dBASE II is an example of a 

relational (or tabular) DBMS that restricts join operations. 

The join columns must be indexed. 

1 SOL-Based System 1 

I I 

1 SQL/DS, IBM j 

I I 

1 ORACLE t Relational Software, Inc. I 

i I 

I I 

i System R, IBM I 

I I 

I QUBL-Based Systems 1 

I I 

I 

I INGRES, Relational Technology, Inc ! 

I I 

j IBM 500, Bri t t on-Lee , Inc ! 

i I 

i Other Relational Systems j 

I I 

I 1 

1 MRBS/LINUS, Honeywell I 

i I 

I I 

I dBASE II, Ashton-Tate 1 

I I 

I I 

' NOMAD, National Compute Sharing Services | 



Figure 5.4 Relational DBMS Products and Vender 

3* Two Modes of Access of, SQL^DS 

SQL/DS can be used either interactively from a 
terminal or via application programs. The interactive 
processor, ISQL, processes SQL commands to perform query and 
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update activities. No application programrri ng is required 
when using ISQL. 7or this type of access, users must he 
connected to a communications control program such as CICS 
or equivalent. 

A second mode of access is via application 
programs. In this mode, SQL/DS commands are embedded in 
standard programming text like COBOL, PL/1, or assembler 
language. These embedded commands are nearly identical to 
the commands that are issued to ISQL. This means that 
application programmers need learn only one data language; 
the single data language can be used from application 
programs or interactively with ISQL. Users claim the near 

identity between ISQL statement and embedded SQL/DS 

statements helps them to develop application programs. 
Programmers can develop database commands interactively, 
verify them for correctness using ISQL, and then include 
those commands in application programs. 

Figure 5.5 shows the processing of embedded SOL/CS 
statements. Programs containing SQL/DS commands are input to 
a precom?piler that examines the statements for correctness 
and builds small SQL/DS access modules that will perform the 
desired database service. These modules are stored in the 
database. At the same time, program instructions are 

inserted Into application programs to call the stored access 
modules when needed. The precompiler generates these 
instructions in standard COBOL or PL/1. As shown in figure 
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5.5, the output of the precompiler Is then input to a 
standard languge compiler for compilation in normal fashion. 



I 1 COBOL Program 

I I with Embedded 

1 I SOL/DS Commands 






SOL/rS COBOL 
Precomple r 




1 ‘S3 COBOL 1 

I Compiler | 







Figure 5.5 Role of SQL/LS Precompiler 

iSi Bisadvantage of E§I§tioO§l B§i§B§§e 
A disadvantage sometimes cited for a relational 
database is machine performance. With present -day hardware 
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the JOIN operation is likely to take substantial machine 
time. It may be feasible with small relations, but some 
commercial files are hundreds of million of bytes long. In 
understanding the performance issue, it is very important to 
remember that the relations and the operations on them such 
as the JOIN will never take place physically. Instead, 
equivalent results will be produced by means of pointer 
structures or indices. 

A relational database design is sometimes depicted 
as not being 'driven' by a user view of the data. A new 
unanticipated user view can be handled with ease if the data 
it needs are stored. Although this is true in connection 
with the logical structure of the data , the new view may not 
be handled with good machine performance because the 
physical structure of the data was designed to best serve 
the most common applications. The physical structure is 
user-driven even if the logical structure is not. 

The advantage of relational database is first of 
all, ease of use. That means the easiest way to represent 
most data is with two dimensional tables. Another advantage 
is flexibility. Users can use PROJECTION and JOIN in the 
form they want. Another advantage is precision. This means 
that the precise results of relational mathematics can be 
applied to the manipulation of relations. Computer security 
is another important application area where the relational 
model should be considered. Security controls can be easily 
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implemented, because security authorizations will relate to 



re lat i ons . 

D. CONVERSION OF SDM INTO RELATION DATABASE DESIGN 
1 . Hela ti o^hip Between Records 

The relationships for the Intelligence Database 
are given in Figure 5.7. Inversion, Matching and Derivation 
will be used to provide inter-relationships between the 
attributes shown. It is possible to find duplicated field 
names using these methods. 
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Figure 5. 


.7 The Relationships between Records 
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2 * S^stern Flowchart and S£la t ion sJiiES 

The system flowchart and relationships between the 
various master files are shown in Figure 5.S. It shows how 
all four master files can he updated automatically hy 
utilizing the Photo master files. The use of simple query 
language will produce a large volume of new data easily and 
quickly. Three SDM facilities will he used to explain how 
it works. 

Initially, the four maste files are created. 
Installation records are sorted according to the IID, and 
Photo records are sorted accordin to the PID. The 
derivation facility will yield the Total-f oe-nnmber from 
the Installation file and the Chserved-weapon-add from the 
Photo file. The inverse facility on the two master files 
yields the new master file called Installation and Photo 
file which includes PNUM and PWC. The derivation facility 
will produce the new-weapon list from the Installation and 
Photo file hy comparing PDAY with previous FEAY. The inverse 
facility on this new master file and the Weapo master file 
will yield the new master file called Installation and Photo 
and Weapon hy comparing VCLASS and WTYPE with ICLASS and 
ITYPE giving us new information such as WAf^MC, WEANG5, 
WFEUL. The final use of IREC, PREC, WREC, AREC files, 
necessitated hy repeating VAMMO groups, yields the new 
master file called Installation, Photo, Weapon, and 
Ammunition giving us the new information such as ALBS, AVAR. 
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Figure 5.8 System Flowchart and Relationships 
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Schema 

After these four records are examined, Inverse and 
Match functions must he deleted in order to achieve DK/NF. 
We have repeating groups, because IREC and WREC have 
multiple values. Repeating groups, however, are prohibited 
in relational databases, so two inte relation constraints, 
AW and ICTEMP, were added. The AW record is composed of 
VCLA3S, WTYRE, and ACAT; and IDTEMP is com.posed of IID, 
ICLASS, and ITYPE. 

Because of interrelation constraints. Weapon class 
and Weapon Type are omitted from IREC, and Wammo is omitted 
from WREC. All attributes are dependent on the primary hey, 
so there are no modification anomalies. The relations in the 
I NTELLICtEN’CE Schema is given in Figure 5.9. 



WREC (WCLASS, WTYPE, WFF , WRANGE, WFEUL , WLES ) 
key : WCLASS + WTYPE 
IREC (ICLASS, IID, lAREA, IPERS, IFF) 

KEY : IID 

PREC (PDAY, PID, PCLASS, PTYPE, PNUM, PWC) 

Key : PDAY + PID + PCL SS + PTYPE 
AREC (ACAT, ALES, AKILL, AWAR) 

KEY : ACAT 
AW (WCT, ACAT) 

! Interrelation Constraints 
IDTEMP (IID, WCT) — 



Figure 5.9 The Relations in the Intelligence Schema 
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Attribute Domains 



Each attribute has its own domain. The value of 
each attribute must be within its domain. The domain of 
each attribute is shown in Figure 5.9. 
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1 

1 

1 

1 

1 

1 


1 

1 

1 

1 


WF? 


FRIEND-OR-FOE 




1 

1 

1 

1 


1 

1 

1 

1 


WRANCxE 


RANGE 




1 

1 

1 

1 


1 

1 

1 

1 


WFUEL 


FUEL-CAP 




1 

1 

1 

1 


1 

1 

1 

1 


VLBS 


MAX-LOAD 




1 

1 

1 

1 


1 

1 

1 

1 


ICLASS 


INS-CLASS 




1 

1 

1 

1 


1 

\ 

1 


IID 


INS-ID 




1 

1 

1 

1 


) 

1 

1 

1 


I ARE A 


AREA 




1 

1 

1 

1 


1 

1 

1 

1 


IPERS 


NO-OF-PERSONS 




1 

1 

1 

1 


1 

1 

1 

1 


IFF 


FEIEND-OR-FOE 




1 

1 

1 

1 


1 

1 

1 

1 


PDAY 


DATE 




1 

1 

1 

1 


1 

1 

1 

1 


PID 


INS-ID 




1 

1 

1 

1 


1 

1 

1 

1 


PCT 


WEAPON-CLASS + 


WEAPON-TYPE 


I 

1 

1 

1 


1 

1 

1 

1 


PNUM 


NUM-OF-WEP 




1 

1 

1 

1 


1 

1 

1 

1 


PWC 


WEATHER 




1 

1 

» 

1 


1 

1 

1 

1 


ACAT 


AMMO-CATEGORY 




1 

1 

1 

1 


1 

1 

1 

1 


ALBS 


MAX-LOAD 




1 

1 

1 

1 


1 

1 

1 

1 


AKILL 


RANGE 




1 

1 

1 

i 


1 

1 

1 


AWAR 


WARHEAD-CAT 




1 

1 

1 



Figure 5.9 Attribute Domains 
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B. A COMPARISON WITH THS NETWORK APPROACHES 

Successful BETG systems lack the f lex i hil i ty of 
relational systems, but they make up for it in being able to 
process larger amounts of data more quickly. Systems like 
this excel at standardized, repetitive applications such as 
online teller processing, or large-scale order entry, and 
the like. They may not be elegent, but they can do large 
amounts of work, and do it well. 

Thus, we have the following situation: relational 
systems are easy to use, applications can be quickly 
developed, but processing of very large amounts of data can 
be unacceptably slow. On the other hand, TETG is more 
difficult to use, but large amounts of work can be quickly 
and efficiently accomplished. The CETG representation of 
the Intelligence Database is given in Appendix E. 

These observations were true in 1983, but development 
efforts are underway in both camps to eliminate the 
shortcomings. Vendors of relational systems are striving to 
improve performance, whereas vendors of nonrela t i ona 1 
systems are attempting to make their systems easier to use. 
One way they are doing this is to give the nonrelational 
systems a relational appearance to the user. 

In the relational approach, all information in the 
database is represented using one construct, end moreover 
this one construct is both simple and familiar. It is 
significant that most of the research since 1970 into such 
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areas as concurrency, locking, security, integrity, view 
definition, etc, has taken the relational approach as a 
starting point, precisely because it provides a clean 
conceptual base. As for the question of an undering theory, 
the realtional approach is not only soundly based on certain 
aspects of mathematical set theory, but it also possesses a 
considerable body of theory in its own right aimed 
specifically at its application to database problems. 

In a relational schema the entire information content 
of the database is represented by means of a single data 
construct, namely, the n-ary relation. In a network schema, 
by contrast, there exits at least one fanset bearing 
information essentially; for it there did not, the schema 
would degenarate into a relational schema with certain 
explicit access paths. In other words, there are at least 
two essential data constructs in the network approach, the 
baseset and fanset. In DETG, in particular, there are five 
data constructs, any or all of which may be used to describe 
essential information: 

* record type (corresponds to baseset); 

* DETG set (corresponds to fanset); 
singular set; 

* ordering; 

* repeating group. 
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VI. IMPLEMENIAIIQN Q 5 Iij£ QRACLE 



The Intelligence database has been implemented using 
the ORACLE relational DBMS . Initially a data file is created 
using CREATE command. After the creation of the IREC file, 
it appears as shown below. 



UFI> CREATE T*rtLE I 

a (iCLAss CHAft(a), 

3 1 1 D ( vy t 

5 IPERS NiMHEP(yi# 



IF- CHAR(3J)T 



Taole created. 



After the table is created, IREC data is added to the 
data file using the INSERT command. 



■jFt> iNsepr into ipsc v^ljes ( • 4 ? ■ , i o i , 3 , isoo, • ^ oe • ) ; 

I reco^i cr-ated. 

LIFI> IMSEPr INTO IREC V^LJES ( * A F * , I 1 0 , I 0 , I E 0 0 , • F 0£ • j ; 
1 crearen. 



After IREC file is created, list all the data in the 
IREC using SELECT, ERCM command. 

uri> select . 

2 he:; 



IC 


no 


T4SE4 


IPE9S 


tFC* 


4F 


101 


8 


1500 


poe 


AF 


1 10 


10 


1800 


F0€ 


PO 


208 


25 


a600 


FR3 


A^ 


318 


3 


2800 


P0€ 


AR 


503 


1 


POO 


POE 


PO 


215 


32 


3900 


POE 


A F 


108 


7 


MOO 


FRO 


PO 


225 


35 


5200 


FD£ 


AR 


510 


5 


3900 


PRO 


PO 


231 


30 


7500 


FRO 


1 0 


reco rds 


selected. 
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are 



In the same vay, 



data for the other relations 



created and are shown uelov. 



List all AF.EC file. 



UF1> SELECT * 

2 a^e:; 



ALiS A<ILL ArtAR 

1 00 1 



A y I 0 

I 7S 

C 510 

0 ^50 

E MOO 

F I 300 

G ^ 

H 135 

I 

J 130 

K 3^0 

L 1^50 

M I 300 

M ISO 

P 150 



S 3 

ISO 1 

SOO ^ 

535 « 

800 5 

I 2 

3 ^ 

I 3 

100 7 

135 ^ 

aoo ^ 

SOO ^ 

3 ^ 

I 10 



15 recor-ts selecten. 



List all WRTC file. 

'JFI> select * 



WCL 


I f Y = E 


F 


.grange 


^FI>EL 


vsLBS 


AC 


1 


F3E 


1 0000 


800 


1 0000 


AC 


3 


fJE 


3000 


700 


1 5000 


AC 


3 


FOE 


5000 


500 


U 000 


AC 


a 


F PD 


ROOO 


600 


1 1000 


AC 


5 


FPO 


M 000 


800 


15000 


AC 


6 


FPD 


5000 


700 


12000 


Sd 


1 


FDE 


30000 


5000 


1 0 0 0 0 0 


Si 


3 


FOE 


25000 


7000 


125000 


SH 


3 


FOE 


1 5000 


6000 


1 1 0000 


Sd 


a 


FPD 


35000 


7000 


1 1 5000 


Sd 


5 


FPO 


30000 


3000 


1 50000 


SH 


6 


FPO 


1 3000 


6000 


1 1 0000 


APU 


\ 


F3E 


5500 


500 


5000 


AdU 


3 


FOE 


1000 


200 


3500 


APU 


3 


F3E 


3000 


500 


aooo 


APU 


a 


FPD 


3000 


600 


6000 


APU 


5 


P PO 


1000 


250 


5000 


AP J 


6 


FPO 


3530 


300 


as 0 0 



I? records selected. 



82 



List all PRFC file 



UFI> 5ELECI • 

2 FROM P9EC; 



PO AY 


PID 


PCL 


PTYPE 


3NUH 


PHC 


301 


310 


Ah^U 


1 


100 


FAIR 


301 


310 


ARIJ 


3 


200 


FA 


301 


316 


ARU 


5 


150 


FAIR 


302 


1 10 


AC 


1 


7 


PCLDY 


302 


2 oa 


SH 


5 


a 


FAIR 


302 


101 


AC 


2 


0 


PCLDY 


302 


215 


SH 


3 


25 


PCLDY 


302 


223 


SH 


3 


0 


PCLDr 


302 


223 


SH 


1 


u 


PLCDY 


302 


303 


APlJ 


2 


200 


FAIR 


303 


1 1 0 


AC 


1 


1 0 


CLOY 


303 


223 


SH 


3 


u 


CLOY 


303 


3l« 


ARIJ 


1 


200 


PCLDY 


303 


231 


SH 


6 


30 


CLDt 



record? se^ecred• 



List all II'TEf^P file. 



UFI> SELECT • 

2 FROM lOTEM^ 



no 


ICL 


I TYPE 


101 


AC 


1 


101 


AC 


3 


1 10 


AC 


1 


110 


AC 


1 


1 10 


AC 


2 


1 10 


AC 


3 


200 


SH 


a 


200 


SH 


6 


310 


ARU 


1 


310 


ARU 


3 


310 


AC 


3 


303 


ARU 


2 


215 


SH 


1 


215 


SH 


3 


215 


AC 


2 


1 00 


AC 


a 


1 0*^ 


AC 


5 


223 


SH 


2 


223 


SH 


3 


223 


AC 


2 


316 


ARU 


u 


316 


ARU 


5 


316 


AC 


6 


231 


SH 


5 


231 


S H 


6 


231 


AC 


5 



2b records selected. 
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List all .sw file 



UFI> 


SELECT 


* 






WCL 


^rrP£ 


A 


AC 


1 


A 


AC 


i 


C 


AC 




fl 


AC 


a 


c 


AC 


3 


R 


AC 


5 


G 


AC 


a 


K 


AC 


a 


L 


AC 


5 


K 


AC 


6 


L 


AC 


6 


P 


SH 


l 


0 


Si 


1 


E 


s^ 


l 


F 


SH 


a 


E 


SH 


a 


F 


SH 


5 


f> 


SH 


a 


M 


SH 


S 


N 


SH 


b 


N 


A^ J 


\ 


G 


A^J 


1 


H 


A^?J 


? 




AHJ 


3 


H 


A^U 


3 


J 


A9U 


a 


P 


A 


a 


P 


A^J 


S 


P 


A^U 


b 


P 


A^?U 


b 


P 



10 rpcoris selpct^l. 



Several samrle queries and the results usin^ ORACLE are 
given below. 

1. List w>^at kinds of Installation Classes are in I EEC 

SELECT U'JlTiUt' ICL^SS 

r c 

AP 

A-? 
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2 . 



List how mary Installation ID Codes are in IRSC. 



UFI> select COUNTHID) 

3 FSOM HEC? 

COUNT ( I ID) 

1 0 

3. List Installation record file sorted by 

Installation ID Code in ascendine order. 



uFi> select * 

2 FPQM i-(e; 

5 OBOES by no; 



IC 


no 


ISRE4 


IPERS 


IFF 


AF 


lOl 


8 


1500 


FO€ 


Af 


109 


7 


1400 


FRO 


AF 


l 10 


10 


1800 


FOE 


P3 


ao8 


2S 


4600 


FRO 


Pa 


ai5 


32 


3P00 


FOE 


P3 


III 


35 


5200 


FO^ 


PO 


231 


30 


7500 


FRO 


AP 


303 


1 


POO 


f'qe 


AP 


316 


5 


3800 


FRO 


AP 


318 


3 


2800 


FOE 



10 records selected. 



4. List how many Friends or Foes are in the 

Installation records where the TF^^ is equal to Foe. 



UEI> SELECT C0UNT([EF) 

? FRO"^ ise: 

J YH£RE IF= = 'FOE': 

COUNU IFF) 
b 

5. For Installation ID Code 113, display the weapons 
(Class/Tyne) observed in the past at the i’^stallation , the 
Day of Photo and Number of Weapons observed which correspond 
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to those weapons observed in the past , ONLY for those 
weapons with a o'axiTiu'r ammo load in excess of 10,500 pounds. 



U'I> ^ 

t select OTE'^P . ICL4SS , I 0TE'<= . I T rO£ , P5EC , ?»£C 

3 lOTE'^P . I 10 = M 

a 4NJ0 nrE'^P.lCLASS = PPEC. <=CLaSS 

s ^"iO nrE'^P.lFYPE = PPEC.PTYP£ 

b 4Njn ppEC.^CLiSs = t-pe: . -^CLAS s 

7 a 'JO P-?PC.‘^TrPt = 'jPEC./jIypE 

8* A'40 AP£C,.4LiS > \nSOO 



i:l iFY^E 

AC ? 



30 AY 
^02 



P N J '•1 



6. Display the Installation ID Code and Area for 



those installations photographed on Day 3?1 for which the 



weapons (Class/Type) ohservei on that day had a maximum 



range in excess of 7, PC'?* meters, and the killing radius of 



all ammunition tyres available exceeds 125 feet. 



UFI> :? 

I select nEC. l 10 , IP£c. IAPSA 

^ r^QM HE:,P9tc..v^ec, aw,a^e: 

3 >^H£»E Ap^c^^kIll > t^s 

^ A'40 Y^EC,.-IPAN3E > 7000 

5 AND P^EC.HOA,^ = 301 

^ Amo 1 9FC , II) = p^ec .Pin 

7* and A.v.ACAT = APEC.ACAT 



III) I AP£A 



SI 8 3 

3 18 3 

3 I S 



7. Display Installation IB Code and the total number 
of weapons observed according to Installation ID Code, 
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weapon classes and weapon type. 



)Fl> SELECT PI0,SD'^(PNIJM) 

a c»n« pPEc 

5 GROUP ’y PID,PCL4SS,PTrP£; 



oyo 


S JM ( ) 


1 0 1 


A 


1 1 0 


1 7 




J 




as 


325 


'4 


3?5 


la 


35 1 


30 


305 


300 


316 


1 so 


31^ 


500 


31P 


aoo 


Display 


Ins ta' 



8 . 

Weapon Type and the total nunber of Weapons Observed, where 
Installation ID Code in INSTALLATION record is equal to that 
of PHOTO record to^rether with Installation Class and Weapon 
class and Weapon tyoe. 



UFI> P 

1 SELECT ICLASS,PCLAS3,PTYPE.SUM(PNUM) 

2 FROM IREC^PREC 

J fliHERE PI5 = no 

«• GROUP 3y iclass.pclass.ptype 



IC PCL 


DT YP£ 


SUM(Onjm ) 


AF AC 


1 


1 7 


AF AC 


a 


8 


AP ARU 


1 


300 


AR ARU 


a 


aoo 


AR ARtj 


5 


aoo 


AR ARU 


5 


ISO 


PO SH 


1 


a 


P3 SH 


5 


37 


P3 SH 


5 


4 


P3 SH 


b 


-50 



10 



selecte'1. 



9. Display Pi ay of Photo for any day that W range is 
greater than Wlbs is greater than and Wfeul is 

600, according to the information in the WRPC record. 



ur I ' 

UF1> 

UFI> 

2 

3 

a 

5 

6 
7 



PDAY 



302 

303 



10. List all field names and its type for Photo 



record. 



SELECT UNIQUE PDAY 
FPDM hPEC» PPEC 
^nEPE ^PANGE > 8000 
AND filSS > 1 0000 
AND -^FJEL > bOO 
and /«PEC.rtCL*SS = PPEC.PCLASS 

AMO rtPEC.^TYOE = ppec.^type; 



U‘^I> OESCPHE P'^EC 



z e 


C 5 1 Z ? 


t y oe 


n a ^ e 


22 


ao 


1 


n u 'T^ e ^ i C 


PDA Y 


22 


UO 


1 


n u ? r i c 




3 




P 


cn^rac r er 


^CL ASS 


22 




1 


numeric 


D| yoF 


22 




1 


numeric 




S 




? 


cbar^crer 


=^MC 



89 



VII. CONCLUSIONS AND RECOMMENDATIONS 



An Intelligence Database system is very complex and 
important, and needs very accurate information to increase 
war power. 

Manual systems can not reduce national defease 

expenditures and make it difficult to obtain accurate 

information from the Intelligence system. Thus, database 
management systems must be used in Intelligence systems in 
order to increase end-user productivity, decrease staff, 
enable work to be done more efficiently, and permit end-us<=r 
management more authority and responsibility. 

Relational database models will be most uteful in 
Intelligence systems, because this model gives structural 
independence for the database and a high level language for 
queries. Normal forms and query optimization techiniques can 
be applied to decrease inefficiency of the relational 
database model in the system design stage. 

When we design a database, the SDM model is very 
important. SDM is a high-level semantics-based database 
description and structuring formalism for the database and 
enhances usability of the database system. 

The output of SDM is a specification that can be used 
to implement the database using a commercial DBMS. The 
output of SDM has two alternatives. If we are going to use 
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DBMS based on the relational model, we will produce a 
relation design. If ve are going to use a DBMS based on the 
CODASYL DBTG model, it will produce a DBTG design. 

If we constructed an SDM model, it would be easy to 
reduce the effort required to convert elational models into 
DBTG models or vice versa. 

Using the output of SDM in the Intelligence system, the 
records are rearranged in order to fit a relational model, 
(e.g., creation of the interrelational constraints). The 
ORACLE DBMS was used to demonstrate an operative relational 
DBMS. The ORACLE database management system is a good 

relational database model, providing a user friendly 

environment, easy to use and fast access to data. 

It seems appropriate to conclude with Codd's statement 
of the objectives for the relational approach [Ref. 12]. They 
are as follows ; 

1. To provide high degree of data independence. 

2. To provide a community view of the data of spartan 

simplicity, so that a wide variety of users in an 

enterprise can interact with a common view (while 

not prohibiting superimposed user views for 
specialized purposes). 

3. To simplify the potentially f rnidable job of the 
database administrator. 

4. To introduce a theoretical foundation into 

database management. 
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5. To rrerge the fact retrieval and file npanagerr'eat 

fields in preparation for the addition at a later 
time of inferential services in the commercial 

world . 

5. To lift database application programming to a new 
level - a level in which sets (and more specially 
relations) are treated as operands instead of 
being processed element by element. 

No one would claim that all these objectives have now been 
attained; much more work remains to be cone. However, a 
strong foundation has been established, and there seems 
good reason to be optimistic about the eventual outcome. 
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APPENDIX A 



ORIGINAL DATA 

Pour record types coastitute the Intelligence retatese 
attached. The following notes and definitions apply to the 
da t aha se . 

1. The Installation, Ammunition and Weapon Records 
represent the status as of the end of day 3?2. The photo 
records represent information obtained on the indicated day 
(not neccessarily in addition to status information on day 
300) . 

2. Defintions 

Installation Class : AP - airfields 

PC - ship ports 
AR - Army units 

Weapon Class : AC - aircraft 
*SH - ship 

APU - armour unit (eg., tank' 

Weapon types are numbered 1, 2, 3, 4, 5, 6, for 

ea h class 

Ammunition categories are letters A , P , C , D , E , P ,G , 

3. The occurence of the database as given is assumed 
to be indicative of the structure in the determination of 
unique keys, record relationships, functional dependencies, 
etc . 

4. Variables have been given different names when 
they appear in different record types. (eg., IID and RID 
both refer to Installation IB Code). 
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5. There are cases where repeating group da*a is 
represented on the page of a particular record type. (eg., 
Weapon Class/Type with Installation Records). 







INSTALLATION RECORDS 


( IREC ) 




ICLASS 


HD 


lAREA 


IPERS 


IFF 


ICLASS/ITYPF 


AF 


101 


8 


1500 


FOE 


\C/1, AC/3 


AP 


110 


10 


1800 


FOE 


AC/1, AC/2, AC /3 


PO 


208 


25 


4600 


FRD 


Sa/4. SH/6 


AR 


318 


3 


2800 


FOE 


ARU/1 ,ARU/3 ,AC/3 


AP. 


303 


1 


900 


FOE 


ARU/2 


PO 


215 


32 


3900 


FOE 


SH/l,SH/3,AC/2 


AF 


108 


7 


1400 


FRD 


AC/4, AC/5 


PO 


223 


35 


5200 


FOE 


SH/2,SH/3,AC/2 


AP 


316 


5 


3800 


FRD 


ARU/4,APU/5 ,AC/6 


PO 


231 


30 


7500 


FRD 


SH/5,SK/5,AC/5 



ICLASS 


: Installation 


Class 


HD 


: Installation 


C ode 


lAREA 


: Area (Square 


i^i les ) 


IPERS 


: Estimated No. 


of Personnel 


IFF 


: Friend or Foe 





ICLASS/ITYPE : Weapon Class/Type Observed In Past 
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AMM.UNITION' RECORDS (AREC) 



ACAT 


ALBS 


AKILL 


AVAR 


A 


410 


100 


1 


E 


175 


5 


3 


C 


510 


150 


1 


D 


9 50 


500 


4 


E 


1100 


525 


4 


F 


1300 


600 


5 


G 


8 


1 


2 


H 


125 


2 


6 


I 


12 


1 


2 


J 


180 


100 


7 


K 


240 


125 


8 


L 


1450 


400 


9 


hi 


1300 


500 


9 


N 


150 


2 


8 


0 


7 


1 


10 



ACAT : AniDO Category 

ALBS ; Weight of One Round (Pounds) 

AKILL : Killing Radius (Feet) 

AWAR : Warhead Category 
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301 

301 

301 

301 

301 

301 

301 

302 

302 

302 

302 

302 

302 

302 

303 

303 

303 

303 



PEOTO PECCP.PS (PREC) 



PID 


PCLASS 


110 


AC 


110 


AC 


206 


SH 


223 


SH 


223 


SH 


318 


ARU 


316 


ARU 


110 


AC 


208 


SH 


101 


AC 


215 ■ 


SH 


223 


SH 


223 


SH 


303 


ARU 


110 


AC 


223 


SH 


318 


ARU 


231 


SH 



PDAY : Cay of 
PID : Install 
PCLASS : Weapo 
PTYPE : Weapon 
PNUM : Number 
PWC : Weather 



PTYPE 

1 

3 

5 

3 

2 

1 

5 

1 

5 
2 

3 

3 

1 

2 

1 

3 

1 

6 

Photo 

ation Code 
n Class 
Type 

of Weapons Ob 
C ond it ion 



PNUM PWC 



5 


PAIR 


6 


FAIR 


4 


PCLDY 


6 


PCLDY 


5 


PCLDY 


100 


FAIR 


200 


FAIR 


7 


PCLDY 


4 


FAIR 


g 


PCLDY 


25 


PCLDY 


Q 


PCLDY 


4 


PCLDY 


200 


FAIR 


10 


CLDY 


4 


CLDY 


200 


PCLDY 


30 


CLDY 



er ved 
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WEAPON RECORDS (PREC) 



WCLASS 


WTYPE 


WF? 


WAMMO 


WRANGE 


WFEUL 


WLRS 


AC 


1 


FOE 


A,C 


10 000 


800 


13000 


AC 


2 


FOE 


F,C 


6000 


700 


15000 


AC 


3 


FOE 


E.G 


5000 


500 


11300 


AC 


4 


FRD 


K,L 


9000 


600 


11000 


AC 


5 


FRD 


K 


11000 


600 


15030 


AC 


a 


FRD 


L,P 


5000 


700 


12000 


SH 


1 


FOE 


D,E,F 


30000 


5000 


100000 


SH 


2 


FOE 


E,F 


25000 


7003 


125303 


SH 


■T. 

'w 


FOE 


D 


15000 


5000 


110000 


SH 


4 


FRD 


M 


35000 


7000 


115000 


SH • 


5 


FRD 


M,N 


20000 


6000 


130000 


SH 


6 


FRD 


N 


120 0 


5000 


110000 


ARU 


1 


FOE 


G,F 


3500 


500 


5000 


ARU 


2 


FOE 


J 


1000 


200 


2500 


ARU 


3 


FOE 


H, J 


3000 


300 


4000 


ARU 


4 


FRD 


P.R 


3000 


600 


6000 


ARU 


5 


FRD 


R 


1000 


250 


3000 


ARU 


6 


FRD 


P.R 


2500 


300 


4500 




WCLASS : 


Weapon Class 









WTYPE : weapon Type 

WFF : Friend or Foe 

WAMMO : Available AMMO Cate^jories 

WRANGE : Maximum Weapon Range 

WFEUL : Feul Capacity (Gallons) 

WLES : Maximum Ammo Load (Pounds) 
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APPENDIX B 



DBTG Schema for Intelligence Database 
Figure B.l presents a data structure diagram of the 
schema design for the Intelligence database. There are seven 
records and six sets. The names of the records and sets are 
shown in Figure B.l. 



PREG 1 



IREC 



WHFC 1 



A 



4 ^ 



PR-IMTEMP 

I 

I 



--»! 



TOT NUMBER 



V 

V 



I 



1 IR IDTEMP 



V 

IDTEMP 



1«- 



X/ I 



IDTEMP AW 



I 

1 WP. 

V 

V 

AW 



I 



V AW^AR 

•XT 



I T NUMBER ! 



ARF( 



Figure B.l DSD for Intelligence 



Figure B.2 shows a schema description for Intelligence. 
This schema describes records, data-items and sets. 
According to the 1981 standard, no punctuation is required 
because keywords indicate the boundaries of phases and 
expressions . 
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SCHEMA name is Intelligence 
Record name is IREC 



duplicates 


are not 


allowed for 


IID 


ICLASS 


type is 


cnarac ter 


2 




check is 


equal ^AF', 


'AP'.'PC' 


IIB 


type is 


fixed 




I A REA 


type is 


fixed 


2 


IPERS 


type is 


fixed 




IFF 


type is 


character 


•X 

*-> 


Record name is 


check is 
PREC 


equal 'FOE' 


, 'FED' 


PDAY 


type is 


fixed 






check is 


less than 366 


PID 


type is 


f i xed 


T 


PCLASS 


type is 


character 




ptype 


type is 


f i xed 


1 


PNUM 


type is 


fixed 


3 


PVC 

Record name is 


type is 
AREC 


cha ra c ter 


5 


duplicates 


are not 


allowed for 


ACAT 


ACAT 


type is 


cha ra cter 


1 


ALBS 


type is 


fixed 


c; 


AKILL 


type is 


f i X ed 


3 


A WAR 

Record name is 


type is 
WREC 


fixed 


2 


dupl icates 


are not 


allowed for 


WCLASS, yTYPI 


WCLASS 


type is 


cha ra cter 


”7 


WTTPE 


type is 


fixed 


1 


WFF 


type is 


chara ctrer 




WRANGE 


type is 


fixed 


K 


WFEUL 


type is 


fixed 


4 


WLBS 

Record name is 


type is 
IBTEMP 


fixed 


6 


dupl icates 


are not allowed for 
IID, ICLASSS, ITYPE 




HE 


type is 


fixed 


T 


ICLASS 


type is 


character 


2 




check is 


equal 'AC', 


'SH' , 'ARU' 


ITYPE 

Record name is 


type is 
AW 


fixed 


1 


dupl i ca te s 


are not 
WCLASS, ’ 


allowed for 
WTYPE, WAMMO 




WCLASS 


type is 


character 


3 


WTYPE 


type is 


fixed 


1 


WAMMO 


type is 


chara cter 


1 


Record name is 


T NUMBER 




TDAY 


type is 


fixed 


0 


TPNUM 


type is 


f ixed 


4 



Figure B.2 CETG Record Schema Description 
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Set 



name is IR_IDTI]r^? 

Owner is IREC 1 

Order is sorted ly defined keys 1 

Member is IDTEMP ! 

Insertion is automatic 1 

Re ten t i on is fixed 1 

Check is IID in IREC = IID in IDTE*^P ! 

and ICLASS in IREC = ICLASS in IDTEMP ! 

and ITYPE in IREC = ITYPE in IDTEMP 
Set selection is by value of ! 

IID, ITYPE, ICLASS I 

Set name is AW_AR I 

Owner is AW 1 

Order is sorted by defined keys ! 

Member is AREC ! 

Insertion is automatic I 

Retention is fixed ! 

Check is WAMMO in AW = ACAT in AREC ! 

Set name is WR_AV 1 

Owner is V/REC 1 

Order is sorted by defined keys I 

Member is AW ! 

Check is WCLASS in WRKC - WCLASS in AW 

and WTYPE in WREC = WTYFE in A'*' 1 

Set name is TOT_NUMBEF, ! 

Owner is PREC 1 

Order is last ! 

Member is T NUMBER 1 

Insertion is manual I 

Retention is optional ! 

Check is PDAY in PREC = PDAY in TNUMBER I 

Set selection is by value of PDAY | 

Set name is PR IDTEMP I 

Owner is FREC ! 

Order is last I 

Member is IDTEMP 1 

Check is PID in PREC = IID in IDTEMP ! 

and FCLASS in PREC = ICLASS in IDTEMP | 

and PTYPE in PREC = ITYPE in IDTEMP j 

Set selection is by value of 1 

PID, PCLASS, PTYPE ! 

Set name is IDtEMP_AW j 

duplicates are not allowed for WCLASS, WTYPE ; 
Owner is IDTEMP I 

Order is sorted by defined keys 1 

Member is AW 1 

Check is ICLASS in IDTEMP = WCLASS in AW 

and ITYPE in IDTEMP = WTYPE in AW 1 



Fig B.3 DBTG Schema Description for Intelligence 



99 



14. 



Fagin, Ronald. ”a Nornal Forn f or^^P.elati onal Datafcase 
That Is Based on Domains and Keys." In Transaction on 
Database Systems, Vcl.”:, No. 3, September T5?l 

15. Codd, F.F. "Relational Database: A Practical Foundation 
for Productivity." In Communications of the AC^, Vol. 
25, No. 2, February 1982. 



101 



LIST OF REFERENCES 



1. Martin, J., Comnuter QlS§Hii§li2r > 

Prentice-Hall Inc., Englewood Cliffs, N.J., 1977. 

2. Ullman, J.D., Princicle of £§tabase Sisten, Computer 
Science Press, Inc. , Rockville, '^'aryland, 1950- 

3. Kronke, D., database Processing, Science Research 

Associates Inc., Chicago, Tronto, 19S3. 

4. Date, C. J., An Introduction to Database Systems, 
Addition-Vesley Publishing Company INc., 1981. 

5. Smith, D.C and Smith, J.M., "Conceptual Database Design" 
iHioiiii 2R Software Design Techn iaufl » 4th, 19S3. 

6. Hawryszki ewycz , I.T., Database Analysis and Design 
Science Research AssociateT Inc. 1984. 

7. Teorey.T.J. and Fry.J.P., Design of Database Struct_urf 

Prentice-Hall, INC, Englewood Cliff N.J 07532. 1982. 

8. Hammer, Michael, and McLeod, Dennis. "Database 

Description with SDM: A Semantic Database Model.” 

In^nsaction on Database Systems, Vol.6, No 3, September 
1981. 

9. Berri, C, Bernstein, R. A., and Goodman, N. 1978. "a 
sophiscate's Introduction to Database Normalization 



- 124. 

10. Zelkowitz, M.V., "Perspectives Software Engineering ", 
Computing Surveys, vol. 10, N0.2, June 1978. 

11. Ts ichr is t z i s , D. C. and Lockovsky, F. H., Data Models, 
Prentice-Hall Inc., Englewood Cliffs, N.J., 1982. 

12. E.F. Codd. "Recent Investigation into Pelational 
Database Systems." Proc. IFIP Congress 1974. Also In 
Proc. ACM Pacific Conference, San Francisco, April 1975. 

13. Codd, E. F. "a Relational Model of Data for Large 
Shared Database." In Communication of the ACM, Vol.R, 
No.6,Junel970 



100 



INITIAL DISTRIBUTION LIST 



Library, Code 0142 
Naval Postgraduate School 
Monterey, Califonia 93943 

Department Chairman, Code 52 
Department of Computer Science 
Naval Postgraduate School 
Monterey, Califonia 93943 

Professor S. H. Parry, Code 55py 
Department of Operation Research 
Naval Postgraduate School 
Monterey, Califonia 93943 

Central Computer Center 
Army Headquarters, 140-01 
Seoul, republic of Korea 

Jang, Jai Eun 
6-512 Soldier APT 
Young-San Dong, Young-San 3u 
Seoul, Republic of Korea 

Chief of Staff 

Army Headquarters, 140-01 

Seoul, Republic of Korea 

Department of Personnel Management 
Army Headquarters, 140-01 
Seoul, Republic of Korea 

Division of Computer Management 
Department of Management 
Army Headquarters, 140-01 
Seoul, Republic of Korea 

Division of Education 
Department of Personnel Management 
Army Headquarters, 140-01 
Seoul, Republic of Korea 



10. Departrrien t of Intelligence Management 1 

Army Headquarters, 140-01 

Seoul, Republic of Korea 

11. CDR Michael, J. Anderson 

Computer Technology Curriculum, Code 37 1 

Naval Postgraduate School 
Monterey, California 93943 

12 . Lee , Hee Young 1 

SMC #2726 

Naval Postgraduate School 
Monterey, California 93943 

12. Lee, Jang Hun 1 

SMC #1366 

Naval Postgraduate School 
Monterey, California 93943 

13. Song, Hwa Dal 1 

SMC #2743 

Naval Postgraduate School 
Monterey, California 93943 

13. Choi, Kwang Jun 1 

SMC #2370 

Naval Postgraduate School 
Monterey, California 93943 

14. Lee, Ju Kah 1 

SMC #2879 

Naval Postgraduate School 
Monterey, California 93943 

15. Defense Technical Information Center 2 

Cameron Station 

Alexandria, Virginia 22314 



103 




1 3 $ 3 7 5 








q 




211913 



Thesis 

Jang 

; . Design and implemen- 

tation of an intel3^- 
gence daiahase* 

13 NGV es ^ J ppB 1987 3 3 3 7 7 

FEB 2 S' w 



211S13 



Jang 

Design and implemen- 
tation of an intellli- 
gence database* 



Thesis 

J283 

c.l 



